Robust high speed sensor interface for remote sensors

ABSTRACT

Systems, methods, and apparatuses are discussed that enable robust, high-speed communication of sensor data. One example system includes a sensor bus, an electronic control unit (ECU), and one or more sensors. The ECU is coupleable to the sensor bus and configured to generate a synchronization signal, and is configured to output the synchronization signal to the sensor bus. The one or more sensors are also coupleable to the sensor bus, and at least one sensor of the one or more sensors is configured to sample sensor data in response to the synchronization signal and to output the sampled sensor data to the sensor bus.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/959,226 filed on Dec. 4, 2015, and incorporated herein by referencein its entirety.

FIELD

The present disclosure relates to a sensor interface for remote sensorsthat can provide improved speed and robustness, with reduced wiringrequirements.

BACKGROUND

Sensors such as speed or position sensors are used to provide feedbackinformation in mechatronic systems, and are thus used as an interfacebetween the mechanical and the electrical domain. In many cases, thepositioning of a sensor is driven by mechanical constraints, forexample, the available constructed space or accessibility of sensingtargets (target wheel, shaft end, etc.). Therefore, in most applicationsthe sensor cannot be embedded into the ECU (electronic control unit) buthas to operate as a standalone sensor (satellite sensor) that has to beconnected to the control unit through a (wired) interface.

The interface is the most critical component in a sensing solution interms of robustness, cost, and performance. Regarding robustness, thecable and connector provide the most significant contribution to theoverall FIT (failures in time) rate. Additionally, the cost of the cableand connectors in combination with the cost of assembly and maintenancecontribute significantly to the total cost of ownership (TCO). In termsof performance, the sensor interface in many conventional systemsprovides the “bottleneck” for the information transfer. While thesensing information (e.g., sensing and diagnostic data) is available ata much higher resolution (in time and/or accuracy) at the sensorlocation, it cannot be transferred and used at that resolution in theECU because of missing connection bandwidth. Additionally, manyconventional interfaces only provide a one-way data link (e.g., sensorto ECU, but not vice versa), thus a dynamic adjustment of sensorparameters or even synchronization between sensor and ECU is notpossible, resulting in performance degradation of the entire system.Finally, most conventional connection schemes are point-to-pointconnections between sensor and ECU. In these situations, complex systemscomprising several remote sensors result in complex wiring harnesses.

Conventional sensor systems mainly use pin-to-pin interfaces forsensors. Typical implementations are single-ended voltage interfaces(with 3 wires per sensor, such as SENT (single edge nibbletransmission), SPC (short PWM (pulse width modulation) code, etc.) orcurrent interfaces (with 2 wires per sensor, such as those used in ABS(anti-lock braking system) or transmission speed sensors). Conventionalinterface varieties include digital voltage interfaces, analog voltageinterfaces, basic current interfaces, and complex current interfaces.

In digital voltage interfaces, SENT is a universal interface used totransfer a digital data stream to the ECU (e.g., unidirectionally)without synchronization and bus capability. SPC is an Infineon-ownedproprietary extension of SENT, enabling synchronization and basic buscapability. The implementation of the physical layer interface is verybasic, thus the available bandwidth (and therefore the resultingbaudrate) of the interface is very limited (20 kBaud). Due to the basicimplementation, the interface exhibits a high vulnerability when exposedto EMI or ESD. The key benefit of SENT/SPC is the low complexity of thephysical layer and the possibility to transfer digital data comprisingboth sensing and diagnostic data. However, due to the low update rate,it is insufficient for many applications (e.g. rotor position sensing).

Analog voltage interfaces provide high bandwidth and maximum flexibilityin terms of system integration. When used as an external sensorinterface, analog links suffer from high vulnerability (e.g., to voltageexposure, EMI, ESD), a high number of signal wires (especially fordifferential signal runs) as well as a lack of capability to transferadditional (e.g., diagnostic) data.

The key benefit of current interfaces is the fact that the informationtransfer can be performed via the sensor supply lines, typicallyresulting in a two-wire interface.

For basic current interfaces, the low cost implementations of thephysical layer exhibit a similar level of vulnerability in terms of EMIand ESD as seen on the voltage interfaces described above. Inconventional implementations, several protocols are used ranging from asimple pulse train reflecting particular position indices (e.g.,transmission speed sensors) up to advanced, proprietary protocols thatincluded a limited set of diagnostic data in the data stream (e.g., theVDA protocol used for wheel speed sensors).

PSI5 (Peripheral Sensor Interface 5) and DSI (Distributed SystemInterface) are examples of complex current interfaces that utilizededicated interface drivers, providing both the physical layer interfaceas well as a low-level data link layer. PSI5 also features asynchronization and low speed downstream communication capability.Despite the high effort in such interfaces, the available data rate isrelatively low (e.g., 192 kBaud gross data rate for PSI5). Anotherdrawback of complex current interfaces is the lack of readily availablestand-alone general purpose transceivers, thus the cost of theseimplementations is too high to find broad market acceptance as a generalpurpose sensor interface.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a system that facilitates highspeed and robust communication with remote sensors according to variousaspects described herein.

FIG. 2 is a block diagram illustrating a sensor configured tocommunicate via a differential sensor interface according to variousaspects described herein.

FIG. 3 is a block diagram illustrating a sensor-to-ECU connectionemploying a differential sensor interface to facilitate communicationsbetween the sensor and ECU according to various aspects describedherein.

FIG. 4 is a diagram illustrating an example transmission protocol forcommunication via a sensor interface according to various aspectsdescribed herein.

FIG. 5 is a block diagram illustrating an example arrangement of asensor cluster employing a differential sensor interface to facilitatecommunications between four sensors and an ECU according to variousaspects described herein.

FIG. 6 is a diagram illustrating an example transmission protocol for abroadcast synchronization pulse, wherein a plurality of sensorssimultaneously sample data, according to various aspects describedherein.

FIG. 7 is a flow diagram illustrating a method that can facilitatecommunication via a sensor interface according to various aspectsdescribed herein.

FIG. 8 is a diagram illustrating an example drive implementation of asensor system according to various aspects described herein.

FIG. 9 is a diagram illustrating a dry double clutch transmissionsystem, showing multiple sensors that can be controlled by an ECU via aninterface according to various aspects described herein.

FIG. 10 is a diagram illustrating an example point-to-point wiringscheme applied in conventional interfaces contrasted with a wiringscheme based on a sensor bus interface according to various aspectsdescribed herein.

FIG. 11 is a diagram illustrating illustrated is an example dog clutchand associated sensor system according to various aspects describedherein.

DETAILED DESCRIPTION

The present disclosure will now be described with reference to theattached drawing figures, wherein like reference numerals are used torefer to like elements throughout, and wherein the illustratedstructures and devices are not necessarily drawn to scale. As utilizedherein, terms “component,” “system,” “interface,” and the like areintended to refer to a computer-related entity, hardware, software(e.g., in execution), and/or firmware. For example, a component can be aprocessor (e.g., a microprocessor, a controller, or other processingdevice), a process running on a processor, a controller, an object, anexecutable, a program, a storage device, a computer, a tablet PC and/ora mobile phone with a processing device. By way of illustration, anapplication running on a server and the server can also be a component.One or more components can reside within a process, and a component canbe localized on one computer and/or distributed between two or morecomputers. A set of elements or a set of other components can bedescribed herein, in which the term “set” can be interpreted as “one ormore.”

Further, these components can execute from various computer readablestorage media having various data structures stored thereon such as witha module, for example. The components can communicate vialocal and/orremote processes such as in accordance with a signal having one or moredata packets (e.g., data from one component interacting with anothercomponent in a local system, distributed system, and/or across anetwork, such as, the Internet, a local area network, a wide areanetwork, or similar network with other systems via the signal).

As another example, a component can be an apparatus with specificfunctionality provided by mechanical parts operated by electric orelectronic circuitry, in which the electric or electronic circuitry canbe operated by a software application or a firmware application executedby one or more processors. The one or more processors can be internal orexternal to the apparatus and can execute at least a part of thesoftware or firmware application. As yet another example, a componentcan be an apparatus that provides specific functionality throughelectronic components without mechanical parts; the electroniccomponents can include one or more processors therein to executesoftware and/or firmware that confer(s), at least in part, thefunctionality of the electronic components.

Use of the word exemplary is intended to present concepts in a concretefashion. As used in this application, the term “or” is intended to meanan inclusive “or” rather than an exclusive “or”. That is, unlessspecified otherwise, or clear from context, “X employs A or B” isintended to mean any of the natural inclusive permutations. That is, ifX employs A; X employs B; or X employs both A and B, then “X employs Aor B” is satisfied under any of the foregoing instances. In addition,the articles “a” and “an” as used in this application and the appendedclaims should generally be construed to mean “one or more” unlessspecified otherwise or clear from context to be directed to a singularform. Furthermore, to the extent that the terms “including”, “includes”,“having”, “has”, “with”, or variants thereof are used in either thedetailed description and the claims, such terms are intended to beinclusive in a manner similar to the term “comprising”.

Embodiments disclosed herein relate to sensor interfaces with multipleadvantageous features. In various aspects, systems and methods describedherein can employ a differential bus interface, including, for example,a widely accepted differential bus interface such as CAN-HS forsensor-to-ECU communication. Line coding can be based on anon-return-to-zero (NRZ) technique, which, as used herein, can includevariations such as NRZ inverted (NRZI), etc. In various aspects, USARTcan be employed for data encoding, and bus resynchronization can beaccomplished via dedicated synchronization and resynchronization bitswithin a data frame. These synchronization and resynchronization bitscan simplify microcontroller requirements (as bit-stuffing is notrequired), and can enable constant message frame length (and thus,pre-defined latency and transfer times). Various embodiments describedherein can include an addressing feature to allow for multiple sensorsto be connected onto the same bus. Additionally, in aspects, asynchronization frame can be employed to enable synchronous sampling ofmultiple sensors.

Embodiments described herein can provide or employ a sensor interfacewith multiple advantages over conventional sensor interfaces. In variousaspects, interfaces described herein can provide: a high update rate(e.g., in some example embodiments, update times of T_(update)=50 μs,scalable down to T_(update)=30 μs, etc.); synchronization features(e.g., from ECU to sensor); bus addressing features (e.g., up to 4participants/bus, or more in various embodiments); defined latency andtransfer times; safe transfer of sensing and sensor diagnostic data;ability to handle high voltage exposure (e.g., automotive batteryvoltage levels, etc.); high levels of EMI (electromagnetic interference)and ESD (electrostatic discharge) robustness; implementations involvingreadily available components; and compatibility with a broad range ofmicrocontrollers.

Referring to FIG. 1, illustrated is a block diagram of a system 100 thatfacilitates high speed and robust communication with remote sensorsaccording to various aspects disclosed herein. System 100 can include anECU 110, a sensor bus 120, and one or more sensors 130 ₁-130 _(N).Although the specific example embodiments discussed herein relate tovehicular sensor systems (e.g., in connection with motors,transmissions, etc.) system 100 can be implemented in a variety ofsettings to sample sensor data of substantially any characteristic(e.g., physical characteristics such as positions/angles, temperatures,magnetic fields, currents, rates of change thereof; chemicalcharacteristics such as the presence, absence, or concentration of asubstance; etc.) and communicate that sensor data via the high speedinterface discussed herein.

The ECU 110 can be coupled to the sensor bus 120 (e.g., via adifferential transceiver), and can communicate with the sensors 130 _(i)via the sensor bus 120. ECU 110 can generate and output asynchronization signal. The synchronization signal or pulse can bothtrigger sampling by at least one of the sensors 130 _(i) and be employedsynchronize the one or more sensors 130 _(i) to a common clock (e.g.,the clock of the ECU, etc.). In some embodiments (e.g., embodiments withmore than one sensor 130 _(i)), the synchronization signal can comprisean address element (e.g., one or more bits) that can indicate the sensoror sensors 130 _(i) to sample sensor data. For example, thesynchronization signal can include at least one synchronization bit(e.g., a dominant bit for synchronization), which can be (in someembodiments, e.g., those with multiple sensors 130 _(i), etc.) followedby the address element, which can comprise one or more address bits,where the number of address bits determines the maximum number ofsensors and/or sensor combinations that can be uniquely identified inthe system (e.g., for 1 bit, two sensors or sensor combinations can beuniquely identified, for 2 bits, four, eight bits, etc.). In variousembodiments, the length of the synchronization pulse can be the samelength as data frames transmitted by the one or more sensors 130 ₁(which can have constant length data frames in such embodiments), andthe address information can be contained in the duty cycle of the frame,which can determine the number of address bits based on the commonlength of the data frames and synchronization pulse.

The sensor bus 120 can be a differential bus (and ECU 110 and sensors130 _(i) can have differential transceivers for transmitting andreceiving via sensor bus 120), and communication via sensor bus 120(e.g., of synchronization signals, sensor data, etc.) can employ any ofa variety of line codings, such as a NRZ (non-return-to-zero) coding,which, as used herein, can include variants on NRZ such as NRZI (NRZinverted), etc.

The one or more sensors 130 _(i) can also be coupled to the sensor bus120 (e.g., with each coupled via an associated differential transceiver,which can be included within a module of that sensor 130 _(i) or adiscrete component). The one or more sensors 130 _(i) can receive thesynchronization signal and can sample sensor data (e.g., via a sensorelement) in response to the synchronization signal. Additionally, theone or more sensors 130; can output the sampled sensor data to thesensor bus 120, where it can be received by the ECU 110.

In some embodiments (e.g., embodiments with more than one sensor 130_(i)), each sensor 130 _(i) can be associated with one or more addresses(e.g., an address unique to the sensor and/or one or more otheraddresses shared with at least one other sensor). In such embodiments,the synchronization signal can comprise an address element thatindicates a selected address, and upon receiving the synchronizationsignal, each sensor 130 _(i) associated with the selected address cansample associated sensor data. In various aspects where at least twosensors 130; is associated with the selected address, this sampling canoccur simultaneously for each of the at least two sensors 130 _(i)associated with the selected address. In some aspects, thesynchronization signal from ECU 110 can be a broadcast synchronizationsignal (e.g., via including a specific address element designated forthe broadcast synchronization signal), wherein each of the sensors 130;samples sensor data in response to the broadcast synchronization signal.

Any sensor 130 _(i) that sampled sensor data in response to thesynchronization signal can then output the sampled sensor data to thesensor bus 120. In various aspects, the outputting of the sensor datacan be in response to the synchronization signal, for example, with thesensor data output based on the timing of the synchronization signal.Additionally, any sensor 130; that is outputting sensor data to thesensor bus 120 can output one or more resynchronization bits (e.g., atthe start of or otherwise within some or all data frames, etc.) that canbe used to facilitate clock synchronization. In some embodiments, alldata frames can have a constant length, while in other embodiments, somedata frames (e.g., those from a first set of one or more sensors, etc.)can have a different length than some other data frames (e.g., thosefrom a second set of one or more sensors, etc.).

For embodiments wherein more than one sensor 130 _(i) samples sensordata based on a single synchronization signal (e.g., comprising anaddress element associated with each of the more than one sensors 130_(i)), those more than one sensors 130 _(i) can output their respectivesensor data at different points in time (e.g, sequentially, with orwithout one outputting immediately after the other, etc.). The order ofoutputting sensor data can be predetermined, for example, based onaddresses uniquely associated with the sensors 130; (e.g., in order ofincreasing or decreasing address, etc.).

Referring to FIG. 2, illustrated is a block diagram of a sensor 200configured to communicate via a differential sensor interface accordingto various aspects disclosed herein. Sensor 200 can include adifferential transceiver 210 and a sensor element 220. In variousaspects, sensor 200 can be employed as a sensor in connection withsystems, methods, and apparatuses discussed herein, such as in system100.

Differential transceiver 210 can be coupled to a sensor bus, such as thedifferential sensor buses discussed herein (e.g., sensor bus 120).Differential transceiver 210 can transmit and receive data via adifferential line coding, such as an NRZ coding. For example,differential transceiver 210 can receive synchronization signals (e.g.,such as those from an ECU such as ECU 110, etc.), and can transmitsampled sensor data (e.g., which can be transmitted along with one ormore resynchronization bits, etc.). In some aspects, sampled sensor datacan be transmitted in response to the synchronization signal (e.g.,based at least in part on the timing of the synchronization signal,etc.).

In response to a synchronization signal being received by differentialtransceiver 210, sensor element 220 can sample sensor data (e.g., valuesassociated with one or more sensed characteristics).

Additionally, in some embodiments (e.g., systems, methods, andapparatuses employing more than one sensor, etc.), sensor 200 can beassociated with one or more addresses, and sensor element 220 can samplesensor data when the synchronization signal received by differentialtransceiver 210 indicates one of the associated addresses via an addresselement. In some aspects, at least one of those addresses can beassociated with only sensor 200, although in other aspects, sensor 200is only associated with one or more addresses that are also associatedwith at least one other sensor. For example, if sensor 200 has a uniqueaddress, a synchronization signal can indicate that address, and onlysensor 200 can sample sensor data in response to that indicated address.In another example, if sensor 200 is associated with one or moreaddresses that are also associated with additional sensors, in responseto a synchronization signal indicated one of those addresses, bothsensor 200 and the one or more additional sensors can sample sensor datasimultaneously.

Referring to FIG. 3, illustrated is a block diagram of a sensor-to-ECUconnection employing a differential sensor interface 330 to facilitatecommunications between the sensor 320 and ECU 310, according to variousaspects described herein. In aspects, embodiments described herein canemploy a digital differential signal transceiver as a physical layer forsensor data transmission. In various embodiments, a variation of theCAN-HS (controller area network—high speed) standard can be used as thephysical layer. CAN-HS is not only a well-established standard in termsof physical layer implementation, but also determines the datalinklayer(s) as described in ISO (International Organization forStandardization) standard 11898 (ISO 11898). However, due to thesignificant data overhead of the ISO11898 required to support generalpurpose multi-master networks with high number of participants (CAN-HSuses identifiers with lengths of either 11 bits or 29 bits), theavailable net data rate on the bus would be way too low if the existingCAN-HS standard were employed as defined. Therefore, in aspectsdescribed herein, an application specific data link layer (e.g., stack)can be employed that is optimized for interfacing to remote sensors withsignificantly reduced overhead.

Bit coding in CAN-HS is based on a NRZ (non-return-to-zero) codingscheme. For proper re-synchronization between transmitter and receiver,ISO11898 specifies a bit stuffing method which ensures a bus statetransition after a maximum of 5 consequent bits of same value. Since bitstuffing requires computing power on both the transceiver as well as thereceiver it is usually implemented in the CAN interface block ofspecific microcontrollers. To enable the use of standardmicrocontrollers that do not feature any CAN interface functionality thesignal on the bus can be encoded in a regular USART (universalsynchronous/asynchronous receiver/transmitter) format (e.g., RS-232,etc.). In contrast to the CAN standard, the re-synchronization inembodiments described herein can be performed via frame synchronizationand re-synchronization bits. For example, in embodiments with more thanone sensor, this can be accomplished via an address header followed by aframe synchronization bit and dedicated resynchronization bits withinthe data frame. Besides the advantage of reduced hardware/softwarecomplexity, including dedicated synchronization (and resynchronization)bits (e.g., as opposed to employing bit stuffing) can ensure predictableframe lengths, which provides the advantage for sensing applications ofenabling predictable interface latency times. In various embodiments,each sensor can employ a constant frame length. Alternatively, in otherembodiments, some or all of the sensors can employ different framelengths from other sensors.

Referring to FIG. 4, illustrated is an example of a transmissionprotocol 400 for communication via a sensor interface according tovarious aspects described herein.

Although FIG. 4 shows a specific example transmission protocol 400employed in connection with specific embodiments to illustrate aspectsdescribed herein, in other embodiments, transmission protocols withother characteristics may be employed. For example, the number ofaddress bits employed in transmission protocol 400 can be selected to beany number of address bits (e.g., 2, 3, 4, 8, etc.) or can be determinedby setting the length of the synchronization pulse the same as thelength of a data frame, or for embodiments with only one sensorconnected via the bus, the address bits can be omitted, as eachsynchronization pulse driven by the ECU will indicate that sensor shouldsample sensor data. Additionally, the number of data bits per data blockcan vary (e.g., other than the eight bits shown in transmission protocol400), as can how often a synchronization or resynchronization bit istransmitted (e.g., other than the every nine bits shown in transmissionprotocol 400), as well as other characteristics of transmission protocol400.

For most applications involving remote sensors, it can be advantageousto synchronize the sensor to the ECU clock domain. To do so, the ECU cangenerate and transmit a synchronization signal to the sensor. In variousembodiments described herein, this synchronization can be achieved by asynchronization pulse (e.g., wherein the bus is driven by the ECU) toinitiate the data sampling and data transfer of the sensor. At the sametime, the length of the synchronization pulse can be used as anaddressing feature. In one example transmission protocol, thesynchronization section consists of 3 bits. The first bit can be setcontinuously dominant (for synchronization) while the consequent twobits can be used to indicate a specific sensor address of a plurality ofsensor addresses. Thus, the example transmission protocol 400 cansupport up to four sensors on one ECU output (alternatively, for a 4 bitsynchronization section, up to 8 sensor addresses could be supported onone ECU output, etc.). Referring to FIG. 5, illustrated is an examplearrangement of a sensor cluster employing a differential sensorinterface 530 to facilitate communications between four sensors 520 andan ECU 510, according to various aspects described herein.

In some aspects, a plurality of sensors connected to the sensor bus canbe configured to sample data at the same time (e.g., a current sensorand a rotor position sensor within a motor control application), withthe plurality of sensors associated with a distinct address of theplurality of addresses. After simultaneously sampling respective sensordata, the data can then be transmitted sequentially. Referring to FIG.6, illustrated is an example transmission protocol 600 for a broadcastsynchronization pulse, wherein a plurality of sensors simultaneouslysample data, according to aspects described herein. As can be seen inFIG. 6, the transmission of the initial synchronization pulse by the ECUincludes an address that is associated with a plurality of sensors forsimultaneous data sampling. After the synchronization pulse, each of theplurality of sensors samples data simultaneously, and then each sensorof the plurality of sensors sequentially transmits the data sampled bythat sensor (e.g., according to a predetermined order, such as in orderof ascending (or descending) addresses of the addresses uniquelyassociated with those sensors, etc.). In embodiments wherein at leastone of the plurality of addresses is used for simultaneous sampling by aplurality of sensors, the maximum number of sensors is reduced for agiven number of address bits (for example, for two address bits, thereare four addresses, which can be assigned to four distinct sensors, tothree distinct sensors and one plurality of sensors for simultaneoussampling, etc.).

Referring to FIG. 7, illustrated is a flow diagram of a method 700 thatcan facilitate communication via a sensor interface according to variousaspects discussed herein. At 702, a synchronization signal can be outputfrom an ECU (e.g., to a differential sensor bus as described herein,etc.), such as synchronization signals discussed herein (e.g., that can,but need not, include an address element, etc.). At 704, thesynchronization signal can be received by one or more sensors (e.g., viathe differential sensor bus). In response to the synchronization signal,at 706, sensor data can be sampled by at least one of the one or moresensors (e.g., if there is only one sensor, by that sensor; by one ormore sensors indicated via an address element of the synchronizationsignal; by all sensors in response to a broadcast synchronizationsignal; etc.). At 708, the at least one sensor can output the sampledsensor data. At 710, the sampled sensor data can be received at the ECU.

Embodiments described herein can be employed in multiple applications.Although the following examples are provided in connection withvehicular (e.g., automotive, etc.) sensor systems, embodiments describedherein can be employed in a diverse range of applications to providecommunication of sensor data via a high speed, robust interface.

In a first example application, a system as described herein can beemployed in a motor control application. Referring to FIG. 8,illustrated is an example drive implementation of a sensor system 800according to various aspects described herein. In many situations (e.g.,high power drives, etc.) the control electronics 810 are separated fromthe motor, thus the rotor position sensor 820 (e.g., at end-of-shaft orout-of-shaft) cannot be embedded into the control ECU. Employing a highspeed interface 830 as described herein to connect the sensor 820 to theECU 810 provides multiple advantages over conventional systems,providing advantages in terms of the availability of sensor data,reduction of connection wires, reduced size and cost of the sensorconnector (which can determine the size of the sensor module it multiplewires are required), and the robustness of the interface (e.g., withrespect to EMI and ESD arising from vicinity to high power wiring orcross-coupling).

In a second set of example applications, embodiments described hereincan provide significant advantages over conventional systems insituations wherein more than one motor is be controlled by one ECU.Referring to FIG. 9, a dry double clutch transmission system isillustrated, showing multiple sensors 920 that can be controlled by anECU via an interface according to various aspects described herein. Inthe example transmission unit shown in FIG. 9, two BLDC (brushlessdirect current) motors are used to perform the control of the doubleclutch; another two BLDC motors are used to position the gear levers.Therefore, a total of four rotor position sensors are required for theapplication.

In accordance with embodiments employing the high speed sensor interfacedescribed herein, four separate sensor cables can be wired to the ECU,and all four sensors can be connected to one single interface.Additionally, other sensors such as oil pressure sensors or gear leverposition feedback sensors can be connected to the bus leading to an evenmore significant reduction of wiring complexity.

Referring to FIG. 10, illustrated is an example point-to-point wiringscheme 1000 applied in conventional interfaces contrasted with a wiringscheme 1010 based on a sensor bus interface employed in connection withvarious aspects described herein. The conventional point-to-pointcurrent wiring scheme 1000 comprises a total of 33 connections to thetransmission control unit. In contrast, the sensor bus wiring schemeemployed in embodiments disclosed herein can reduce the number ofconnections to four. However, to for increased safety, the sensors canbe split into two groups resulting in a total of eight connections, asshown in the wiring scheme 1010.

In a third set of examples, embodiments described herein can be employedin connection with systems reliant on simultaneous data from more thanone sensor.

Traditional clutch systems (e.g., dry clutch, wet clutch) are controlledby applying a pressure to the friction plates. The only feedbackparameter required for the control loop is the residual slip of theclutch, and this information can be easily taken by a basic speedmeasurement of both the input and output shaft. However, due to theincreased efficiency, dog clutches are introduced in more advancedtransmission systems. Referring to FIG. 11, illustrated is an exampledog clutch and associated sensor system. As can be seen in FIG. 11, doggears employed in dog clutches have more space than traditional gears,so that teeth butt up against each other, rather than meshing directly.

While conventional clutches can be closed at any phase relation betweenthe plates, closing a dog clutch requires synchronization of both thespeeds and absolute shaft angles of both shafts. Thus, a sensor clusterthat provides the relevant information (angle, speed, acceleration) athigh update rates is important. Embodiments employing the sensorinterface discussed herein can provide significant benefits, in termsof: reduced wiring complexity; the ability to synchronize the sensorcluster to obtain higher sensing accuracy; and the ability to transferadditional information (e.g., diagnostic information that can be used tovalidate sensor data, leading to greater functional safety, etc.).

The above description of illustrated embodiments of the subjectdisclosure, including what is described in the Abstract, is not intendedto be exhaustive or to limit the disclosed embodiments to the preciseforms disclosed. While specific embodiments and examples are describedherein for illustrative purposes, various modifications are possiblethat are considered within the scope of such embodiments and examples,as those skilled in the relevant art can recognize.

In this regard, while the disclosed subject matter has been described inconnection with various embodiments and corresponding Figures, whereapplicable, it is to be understood that other similar embodiments can beused or modifications and additions can be made to the describedembodiments for performing the same, similar, alternative, or substitutefunction of the disclosed subject matter without deviating therefrom.Therefore, the disclosed subject matter should not be limited to anysingle embodiment described herein, but rather should be construed inbreadth and scope in accordance with the appended claims below.

In particular regard to the various functions performed by the abovedescribed components or structures (assemblies, devices, circuits,systems, etc.), the terms (including a reference to a “means”) used todescribe such components are intended to correspond, unless otherwiseindicated, to any component or structure which performs the specifiedfunction of the described component (e.g., that is functionallyequivalent), even though not structurally equivalent to the disclosedstructure which performs the function in the herein illustratedexemplary implementations. In addition, while a particular feature mayhave been disclosed with respect to only one of several implementations,such feature may be combined with one or more other features of theother implementations as may be desired and advantageous for any givenor particular application.

1-21. (canceled)
 22. A system, comprising: a sensor bus; an electroniccontrol unit (ECU) couplable to the sensor bus and configured togenerate a synchronization signal, wherein the ECU is configured tooutput the synchronization signal to the sensor bus; and one or moresensors couplable to the sensor bus, wherein at least one sensor of theone or more sensors is configured to acquire respective sensor data andto output a respective digital representation of the respective sensordata in a respective frame to the sensor bus, wherein the respectivesensor data represented by the respective digital representation has apredetermined latency relative to the synchronization signal.
 23. Thesystem of claim 22, wherein the one or more sensors are a plurality ofsensors, wherein each of the plurality of sensors is configured toacquire respective sensor data and to output a respective digitalrepresentation of the respective sensor data in a respective frame tothe sensor bus.
 24. The system of claim 23, wherein the plurality ofsensors are configured to sequentially output the respective digitalrepresentations to the sensor bus.
 25. The system of claim 23, whereineach of the plurality of sensors are configured to output the respectivedigital representations in a predetermined order.
 26. The system ofclaim 23, wherein the synchronization signal initiates output of eachrespective digital representation from the plurality of sensors.
 27. Thesystem of claim 23, wherein each respective digital representation has apre-defined latency relative to the synchronization signal.
 28. Asensor, comprising: one or more components to: acquire sensor data;receive a synchronization signal; and output a digital representation ofthe sensor data in a respective frame, wherein the sensor datarepresented by the digital representation has a predetermined latencyrelative to the synchronization signal.
 29. The sensor of claim 28,wherein the synchronization signal initiates output of the digitalrepresentation.
 30. The sensor of claim 28, wherein the digitalrepresentation is output in sequence with digital representations ofsensor data from other sensors.
 31. An electronic control unit (ECU),comprising: one or more components to: generate a synchronizationsignal; output the synchronization signal to one or more sensors via asensor bus; and receive at least one respective digital representationof respective sensor data in a respective frame from the one or moresensors via the sensor bus, wherein the respective sensor datarepresented by the digital representation has a predetermined latencyrelative to the synchronization signal.
 32. The ECU of claim 31, whereinthe one or more sensors are a plurality of sensors, and wherein the oneor more components, when receiving the at least one respective digitalrepresentation, are to: receive a respective digital representation in arespective frame from each of the plurality of sensors.
 33. The ECU ofclaim 32, wherein the respective digital representations are receivedsequentially from the plurality of sensors.
 34. The ECU of claim 32,wherein the respective digital representations are received in apredetermined order.
 35. The ECU of claim 32, wherein thesynchronization signal initiates output of each respective digitalrepresentation from the plurality of sensors.
 36. The ECU of claim 32,wherein each respective digital representation has a pre-defined latencyrelative to the synchronization signal.